Websites have greatly proliferated in recent years. The number of services provided by websites has also grown quite rapidly, to the point that almost any type of service may now be obtained via the Internet. The growth in the number of websites has largely occurred without any concerted effort to integrate the various sites. That is, each website has typically been created and maintained as a standalone site, and has generally not been constructed to interact, cooperate, or share information with other websites. As a result, users generally have to maintain a separate and distinct user account on each website. For example, a user may have one account on a book vending website, another account on a computer system vending website, yet another account on a travel agency website, and so on. Having all of these accounts generally forces the user to remember a user name and password for each account. In addition, because each website is its own standalone site, the user typically has to log in separately to each website to use the services provided thereon. Furthermore, the user generally has to provide the same set of information (e.g. first name, last name, address, etc.) over and over again to the various sites, which can be time consuming and tedious.
In an attempt to enable separate websites to interact and share information with each other (thereby, easing the burden on the user), an organization known as the Liberty Alliance has been formed. The Liberty Alliance is a standards organization that has established a Liberty standard, which governs interaction between various websites. The Liberty standard sets forth standard protocols and schemas that can be used to facilitate such interaction. As it currently stands, the Liberty standard comprises two major aspects: a federation framework and a web services framework.
The federation framework makes it possible to set up a circle of trust among a plurality of websites. Within this circle of trust, account linking can be implemented such that an account on one website can be mapped to an account on another website. With such account linking, it is possible to achieve single sign-on (SSO), whereby a user logs in to an account on just one of the websites within the circle of trust and can thereafter access accounts on other websites within the circle of trust without having to log in to those websites. While the accounts on the various websites are linked, the information in the accounts is not necessarily shared (unless the parties specifically agree to share some or all of the information). Thus, with the federation framework, the information in each account remains private to its associated website.
The web services framework enables information to be easily shared among a plurality of websites. With the web services framework, a user can maintain information in a central repository located at one of the websites, and can direct other websites to consult that central repository to obtain information pertaining to the user. For example, a user can maintain his personal profile information (e.g. name, address, phone number, etc.) at a website A. When the user visits a website B (which may, for example, be a website that sells certain goods), and website B requires certain information about the user (for example, an address to which to ship a purchased item), website B can request the user information from website A. With the web services framework, the user does not have to provide his information to each website that he patronizes.
Some application servers that provide SSO service include BEA's Weblogic™, IBM's Websphere™, and Sun's Access Manager™. Sun's Access Manager may also be used in conjunction with (i.e. run on top of) other application servers and web servers to provide the SSO services. Access Manager (AM) servers implement SSO at a different level than other application servers, and are thus able to employ SSO and capabilities independent of the application servers on which they might be executing. AM servers will be used hereinafter in discussing SSO and a failover mechanism associated with SSO.
When a client process requests access to resources from an AM server, the client may be a “dumb” client, such as a web browser, or one or more “intelligent” clients, such as some applications. Using a web browser as an example, when a user first requests access to an account and authenticates herself, a cookie is created on the web browser. Also, a session is created on the AM. The AM that creates the session owns the session. If the user logs out, there must be a single authority to say whether the session is still valid.
A session contains information related to the user's authentication, when the user logged on, how long the user has been idle, the expiry time, and other attributes. In the case of a “dumb” client, the session information also maintains the work that the client has performed thus far. However, an “intelligent” client is intelligent enough to retain its own state, or the work performed thus far.
When the user accesses a second AM server in the trusted network with a web browser, either within the same enterprise or a different enterprise, the cookie is presented to the second AM server. The cookie contains a session token, which is typically a 64-bit number that specifically identifies the session originally created when the user first logged on. The second AM validates the session token by making a back channel call to the first AM server which owns the session. The first AM server verifies to the second AM server that the user has been authenticated and that the particular session associated with the user has not expired. The second AM server then allows the user access to resources provided by the server associated with the second AM server. This communication between the AM servers is transparent to the user; thus, the user can travel amongst different websites without having to re-authenticate and without knowledge of the validation process.